BPStudy-163 事業をエンジニアリングする技術者たち
BPStudy#163〜事業をエンジニアリングする技術者たち
第1部 BPStudyラジオスペシャル〜事業をエンジニアリングする技術者たち
Q: fluct、Zucksが運営しているような、事業に直結するミッションクリティカルなシステムを安定運用するために、チームで決まっている運用方針やプロセス、考え方があれば教えてください。
A: 河村: 何があってもレスポンスを止めない
A: すずけん: 広告は分散システムで事業者をまたいだフェイルオーバーの仕組み。fluctでは余白ができちゃうと機会損失になるので、広告を出しつづけるように工夫が必要。アプリケーションメトリクス、モニタリングメトリクスをとるようにして、回転させていく。守りよりは攻め。検知する仕組みに投資する。DSPとSSPの接続のために（メモ取りきれず）
Q: 第2章に「新しくジョインしてきた人がオンボーディングして最初に価値を提供するまでのリードタイムが必ず1日以内」とありましたが、システムの全体像や開発の流れなどを把握するだけでもけっこう大変なんじゃないかと思います。そのへんは後回しにして、技術的なキャッチアップを優先している感じですか？
A: 河村: 超簡単なタスクを用意しておいて、ここを見れば分かる、というように用意して置いてます。なぜ1日でやるのか、というと、価値を届けることを最初にやることで、みんなでイイネ！これからよろしくね、というセレモニーみたいな感じにしています。中途の人もインターンのひとも同じ入り方をしている。そこを足がかりに枝葉を延ばしてもらう。
A: すずけん: Zucksの強烈な文化ですよね。fluctでも1週間くらいでデプロイまでもっていってほしいけど、なかなか。申請を無くす、調整事をなくすといった取り組みはしているけど、1日でデプロイという施策はインパクトがある。
Q: 2章では「本気で採用ページを書いた」とありましたが、以前と比べて応募者の変化はありましたか？
A: 河村: 書いただけじゃやっぱり来ない。書類選考でみて、熱い想いを持ってそうな人をみつけるようにした。「いままでできなかった事ができるようになる」と思った人が来てくれるようになった。Zucksでも中途は力を入れて無くてリファラルに頼っていたけれど、いま新しくトライしているところ。
A: すずけん: 自分たちでなにを期待しているのかの言語化ができた
A: 小賀: エージェント会社に説明しやすくなった、理解度が上がってマッチ度があがったと思う。
Q: 1章で「たまに（技術的負債を返済できる）すごい腕力を持った人が育ってくる」とありました。そういった可能性のある人を採用するような工夫はなにかしていますか？
A: すずけん: 採用と育成の両方。そういうことができそうな人を採用する。まわりにそういう人がたくさんいること、チームに余裕があること。余裕があればトライができる。長期的にやるからこそいまここでやったほうがいい、という発想を持てるようになる。それで行動すれば腕力がある人の能力が伸びていく。
A: すずけん: 自分のキャパシティの3倍くらいのタスクが降ってくると能力が伸びる。そういうことが普段の仕事でもできるように余白を持たせる
Q: haru: 余白は会社全体でもたせる方針にしている？
A: 小賀: 余白を持てるときと持てないときがある。事業立ち上げ時には立ち上げが優先になる。
Q: 「夜中に何か問題が起きてもすぐに対応しなくて済むような仕組み」「カラムを消さない」などは実践ならではのノウハウという感じがします。こういったノウハウを新しいメンバーに伝えるのはどうしていますか？Wikiに残さないと失われそうだし、形骸化させずに伝承していく方法があれば知りたいです。
A: 河村: レビューで伝えていっているのが現状。Wikiとかは残さないですね。設計ドキュメントみたいなものはまとまったドキュメントに書いておいて共有することはしている。本当はもうちょっと流動性を高めていきたい。そのとき文化をどう残していけるかは模索中。
A: 小賀: Zucksでレビューしてる観点は細かいところではなく「ダメそうなところはないか」「戻せるようになっているのか」にフォーカスしていると聞いている。
A: 河村: そのとおりで、いまはそれでうまく回せている
A: 小賀: 過去の知見を伝えるだけではみにつかない、経験させてそこから教えることでみにつけていく。
コードはあるていどきたなくていいい？
A: 河村: コードの読みやすさについては暗黙知的にみんな「このくらい綺麗にしないとみんな読めないだろ」といったことは意識していると思う。
A: 小賀: PRを分割するということはしているよね。大きすぎるPRは差し戻して、分割させる。分割してリリースすることで安全性を確保するということはやっている。
Q: コードに触れないメンバー（QA等）が参加する案件ではやはりドキュメントが必要と思います。VOYAGEではQAのようなメンバーはいないんでしょうか？
A: 河村: ぜんぶ自分たちでテストしてます
A: すずけん: VOYAGE全体でQA担当というひとはいない。ほんとうはやりたいんだけど
A: 小賀: 広告はほんとうに色々な環境でうごくので、事前にテストするより検知することを優先している。
Q: カナリーサーバーはVOYAGEの場合どんな感じで問題を検知するんでしょうか？
A: すずけん: カナリーサーバーをそれぞれのセクションの1台において、そこにまずリリースしてメトリクスをしっかり確認する。問題なければ残りのサーバーにもリリースしていく。
A: すずけん: カナリーサーバーが1台で良いと思ってたら、あるセクションの一部だけおかしくて、セクション毎に1台ずつひつようになってしまった
Q: エンジニアにとって大事な考え方や姿勢はなんだと思いますか？
A: 小賀: 事業をエンジニアリングする、という考え方が大事だなと思ってます。そのとき、技術の好き嫌いではなく、事業に必要な技術にチャレンジしていく、キャッチアップしていくのが大事だと思っています。変化の激しい中で生き抜いていくのが大事。
A: すずけん: 変化に対応する、というのが大きい。技術スタックもかわっていくので、どんどん取り込んで変化を楽しんでいける人が活躍していけると思う。
haru: 障害が出てヘコむより、新しい障害を楽しむくらいがいいのかもしれないですね
A: 河村: 前の2人に全部言われちゃったw、変化を楽しめるエンジニアが中心になっていけると思う
Q: CTOになるまでに、どのような仕事やキャリアを経てきましたか。また、仕事で大事にしてきたことがあれば教えてください。
A: すずけん: fluctのCTOをやってくれと言われたのが2年くらい前で、ずっとコードを書いていたいと思っていたら回り回ってそうなってしまった。広告事業のなかでチームの立ち上げや解散をなんどもやってきたこともあってその経緯もあって今CTOにおちついた感じ。チームが楽しく開発できると良いと思ってます
A: 河村: 元はネットワークエンジニアで、SNMPをたたいたりしてました。HRPの会社にいったり、SIにもどったりしてきました。その頃（12年くらいまえ）にインターネット広告にであって、某社が日本法人をたちあげたところにjoinして、2016年頃にVOYAGEさんからこえをかけられて参加した。大変といえば大変ですが面白いポイントを見つけながらやってきてます。大事にしてきたのは「楽しみポイントを見つけながらやってきた」ところ。たまに文句はこぼれるけど、楽しんでやってます
A: 小賀: 最初はSIerでプログラム書いてて、「プログラム書いてお金もらえるならそれでいいやー」という感じだったけど、SIerだとプログラムが実際には使われないこともあった。使われないより使われた方が良いとおもうようになった。その後Yahooに移って、良いチームを作って、良いチームでも売上なければチーム解散しちゃうので、売れるものを作ろうという発想になった。その後起業しようとして失敗して、やっぱりチームで仕事をしたくなってVOYAGEに入った。良いチーム、売れる物、をめざしていったら結果的にCTOになった。コアな考え方は「良いものを作りたい」「良いチームで作りたい」この2つを維持するには、儲かる会社、ちゃんとした組織が必要、そのためにそれを維持することに注力しています。